Subject: Minutes of AIW 10 HPR SIG meeting

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Fri, 5 Apr 96 11:35:44 EST

_______________________________________________________________________

                           M I N U T E S
                              HPR SIG
                    AIW 10 - San Jose, California
_______________________________________________________________________

Approximately 40 people attended the March 25, 1996 HPR SIG meeting.
My proposed agenda was satisfactory.

First I recognized several members' contributions by awarding Jim Cobban
(Nortel) an HPR T-shirt.  "Profant_Dan" took the prize for sheer quantity
of contributions ;-).  We reflected on our charter and milestones.  At
AIW 3 we became a SIG and IBM contributed the initial HPR draft, which
progressed to AD, AP and CP at AIWs 5-7 respectively.  At AIW 8, HPR/ATM
was added to our charter and IBM offered a first draft.  After updates,
it received AD at AIW 9.

Ray Bird (IBM, HPR editor) covered minor updates to the base HPR
architecture.  The update is called HPR6 and is now available on an IBM
CD-ROM as document number SV40-1018-00.  He explained:
  - Route Setup Processing check for CN bit
  - List of retriable sense codes
  - Setting the time sensitive bit in NHDR
  - Ignore data loss on old path when doing path switch with respect to
    ARB.  Remember sequence number of packet.
  - RTP Re-FIFO timer changed to be 10 times SRT, to handle subarea
    MLTGs with disparate link speeds.
  - ARB on packet loss - decreasing the increment by a smaller amount

A significant discussion of LLC2 formats for HPR over frame relay ensued.
Jim Cobban presented a "SAP Multiplexing" tower for an alternate HPR/FR
encapsulation.  Some details are summarized here.  The SIG considered the
proposal's interoperation with existing HPR nodes.  A product with the
new tower would indicate its receive-SAP by including the SAP in a new
CV80 (relying on an assumption that existing HPR nodes comply with the
architecture by not sending or recognizing SF80 in CV61 on XID3.)  Choon
Lee believed 3Com's product may be sending CV80; he will check.  We
discussed how the default HPR SAP (C8) fits into the proposal.  I polled
current HPR implementers at the meeting and declared a consensus to add
this option set.  I later reversed myself and asked Jim for a written
proposal to give any products absent from the meeting the usual 2-week
opportunity for input.  I will declare the start of this 2-week period as
soon as Ray distributes updated change pages.

Gary Dudley (IBM, editor of HPR/ATM) went over the latest draft, ATM-03.
 - It was previously proposed that ATM Forum UNI 3.1 be base and UNI 3.0
   be an option.  As no objection was received, this change was included.
 - Effective capacity for ATM TGs was updated to reflect the
   ATM cell overhead
 - Unsuccessful SVC activation - sense data 2.11.3 - sequences 2.7.1.1
 - LDLC DEACT clarification
     - Jim Cobban said this adds a new signal from CS to DLC.
     - I said interprocess flows are not binding on an implementation.
     - Ray said CS knows when to do it and can trigger DLC
     - Marcia invited Jim to submit alternate internal flows.
     - Gary said he modeled this based on configuration parameters from
       NOF to CS, and that the flow was from CS to the LDLC subcomponent
       of DLC.  Jim agreed this was okay.
 - ATM's Explicit Forward Congestion Indication should be handled
   similarly to FECN on FR.
 - New im plementation options for access port bandwidth management
 - New appendix for enhanced session-level pacing - may want to take it
   to the APPN Archecture Reference SIG or the CPIC RIG.
 - LDLC FSMs
 - Configuration Paramaters
   Matthew Finlayson (DCL) asked is there no longer TG negotion for
   parallel TGs?  Gary did not realize his design differed from current
   architecture and will address the question offline.
 - Dedicated SVC Protocol
 - ATM signaling information
 - Appendix added for format changes
 - Gary asked for input to define base and options.  This topic was
   discussion at length later in the meeting.
 - Matthew asked why we don't need liveness functions if sharing an SVC
   with multiple protocols and the APPN stack at other end goes down.
   Ray reported that the IBM products had said it wouldn't happen.  But
   Matthew thinks it could, if the stacks run on separate cards.  I
   encouraged the group to think about this some more and determine if it
   is an issue.

Jim Cobban suggested a different encoding be picked for functional
routing in the NLP header control bytes 1-2, because when CB 1 bit 3 is
assigned, the format could be confused with the subarea VR's TG sweep
field.  No action was taken on this, but Ray agreed to change if possible
(he now suggests 101).

Matthew asked if HPR/ATM changes the max BTU size reported in XID.  Gary
will clarify that max BTU = 32K.

A topic raised at AIW 9 -- multiplexing campus VCs on WAN VC's -- was
further considered. Jim Cobban said it is solved by his LLC SAP
multiplexing proposal later on the agenda.  Gene Cox (IBM) asked why
customers desiring this multiplexing wouldn't just provision an ATM
virtual pipe (VP).  Jim replied that VPs will be expensive due to being
in limited supply.

The next topic, SAP multiplexing, presented by Jim Cobban, was, in my
view, the highlight of the meeting.  First he outlined problems and
requirements:

The current proposed HPR/ATM encapsulation makes hybrid DLC-layer
gateways difficult without an HPR-aware gateway box.  Hybrid gateways
could include a FR-to-ATM service interworking unit (SI - defined by the
ATM-F) or LAN-to-ATM box, or simply ATM-ATM many-VCs-to-one-VC
multiplexing.  A key issue with the first two is the gateway cost; an
issue for the latter is cost to the user.

Second, he articulated a goal, also supported by IBM and Cisco, to
eventually phase out LLC2 in favor of LDLC on all media:  FR, LAN, PPP,
SMDS, etc.  LLC2 disadvantages include timers, windows, transmission,
adapter hardware cost, and disadvantage with respect to IP.

Jim showed a diagram proposing a new HPR/ATM encapsulation based on RFC
1483, which is more consistent with HPR/FR formats (facilitating FR-ATM
SI).  I hope my summary below is correct; Jim's submission, when
incorporated into the HPR/ATM draft, of course overrides mine.  And mail
systems do not translate ASCII graphics the same, so I hope this diagram
is readable!

  ZDDDDDDDDDDDDDDDDDD?
 03    FE   3    FE   3
  DDDDDDDDDEDDDDDDDDD

 23  UI=03  3 NLPID=093 DDQ.9321
  DDDDDDDDDEDDDDDDDDD

 43    4C   3    80   3
  DDDDDDDDDEDDDDDDDDD

 63    70   3    85   3
  DDDDDDDDDEDDDDDDDDD

 83 DSAP=xx 3 SSAP=yy 3   3   04    3   04    3   3   00   3   xx   3
  DDDDDDDDDEDDDDDDDDD
   DDDDDDDDDEDDDDDDDDD
   DDDDDDDDEDDDDDDDD

103  UI=03  3         3   3 XID=BF  3         3   3TEST=F3 3        3
  DDDDDDDDDY         3   DDDDDDDDDY         3   DDDDDDDDY        3
  3                   3   3                   3   3                 3
  /       NLP         /   /   XID I-field     /   /   Test I-field  /
  /                   /   /                   /   /                 /
  3  (data or LDLC)   3   3                   3   3                 3
  @DDDDDDDDDDDDDDDDDDDY   @DDDDDDDDDDDDDDDDDDDY   @DDDDDDDDDDDDDDDDDY

This format is for HPR only, AAL5, when both sides support LDLC.  XID
with CV 6180 negotiates LDLC support.  If LDLC is agreed to, there is no
SABME/UA exchange; instead functional routing in the ANR header is used.
Gene Cox asked if we want to allow test frames.  We decided yes.

Ray Bird assumed the diagram represents ATM only.  Jim replied that bytes
0-7 are ATM-specific; bytes 8-n (DSAP...) are media independent.
Therefore bytes 0-7 would go into the HPR/ATM spec and the rest into the
base document.  Jim said an HPR/ATM station does not have to send Test,
but must respond to it (in case the ATM net is bridged to a legacy LAN).
A station may send DM in response to an unrecognized frame.  (Ray, upon
further reflection, suggests it is OK to discard unrecognized frames.)
Gene summarized this as IEEE 802.2 LLC Type 1, plus the command/response
bit in the SSAP.

We discussed features of the proposal.  LDLC will retransmit XIDs as
needed.  This XID format matches ISR/ATM.  The endpoints can negotiate
LDLC use.  If (LDLC, LDLC), use LDLC.  If (LDLC, no LDLC), use LLC2.  If
the LDLC station doesn't support the LLC2 tower, it reports the problem
with XID3 CV22 pointing to the bit in error and the two are unable to
communicate.

We discussed how two endpoints agree on support.  Suggestions included
negotiation using 1 or 2 bits on XID3 CV61, or configuration.

We discussed liveness, needed on a connection for the benefit of
interoperating (through a gateway) with HPR on a legacy LAN (because
partner liveness cannot be determined from the physical medium's status.)
I pointed out that the liveness function need not be forced into the
HPR/ATM end system; it could be implemented in the gateway.  Steve Berl
(Cisco) said a node only has to answer liveness messages, not send them;
Jim Cobban agreed.  Gene Cox and Roy Brabson (IBM) said a Test frame
could serve this purpose.

I summarized this with the following diagram of proposed base and options
for HPR/ATM:

ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 LLC2 support               3 LDLC option to send      3
3  - APPN with no HPR support3 Test as a keep-alive     3
3  - HPR with ERP            3                          3
3  - HPR with control flows  3                          3
3    on FID2                 3                          3
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

3 HPR/ATM base            - receive and respond to Test 3
3  - LDLC                 - control flows on RTP        3
3  - LLC1                 - no ERP                      3
3  - CV 6180              - no ISR                      3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY

The group felt that they would grant electronic AP once HPR/ATM is
updated to reflect the above design.  Jim will submit his proposal in
writing to the two editors for incorporation of each part into the
appropriate document.  When they are ready I will declare a 2-week review
period for electronic AP for HPR/ATM and for the addition of the SAP
multiplexing option set to the base HPR specification.

Matthew raised application-specified QoS again.  Gary replied that it is
already addressed in the current design by mode definitions, referring to
pp. 2-29 and 30.

The meeting adjourned amicably.

_________________________________________________________________________
 Marcia L. Peters, Chair                    Marcia_Peters @ vnet.ibm.com
 Advanced Peer-to-Peer Networking
 IBM Corp., Dept. BUFA, Bldg. 664
 P.O. Box 12195                             Phone:         (919) 254-4380
 Research Triangle Park, NC 27709           Fax:           (919) 254-5483